Durch den SELFHTML-Forums-Thread Die Hölle der tausend Logins angeregt, sei dieses Thema hier mal angesprochen: Anfangs waren es bei mir und wahrscheinlich auch bei vielen anderen Usern vielleicht zwei oder drei Websites, die gegen Registrierung einen Mehrwert boten, für den sich die Registrierung lohnte. Doch die Zahl solcher Websites steigt stetig, und so sammeln sich im Laufe der Zeit Dutzende von Accounts an.
Nun weiß eigentlich jeder User, dass es unvorsichtig ist, sich überall die gleichen Zugangsdaten zu vergeben. Abgesehen davon ist das auch gar nicht immer möglich, da manche Websites bestimmte Anforderungen an Benutzernamen und/oder Passwort stellen, oder die Wunschdaten sind schon vergeben. Ebenfalls sehr unvorsichtig ist es, alle Zugangsdaten unverschlüsselt auf dem eigenen Rechner abzulegen. Nun gibt es Programme wie den Passwort-Tresor, die sich dessen annehmen. Der Vorteil solcher Programme ist, dass sie nicht nur Web-Accounts speichern, sondern auch Mail-Accounts, Internetzugangsdaten usw. Der Nachteil von Programmen wie dem Passwort-Tresor ist, dass die Daten alle eingepflegt werden müssen, dass das Programm ständig aktiv sein muss, um die Daten schnell parat zu haben, und dass es auf allen Rechnern an allen Orten laufen müsste, über die man die Zugänge benötigt. Web-Browser unterstützen ja ebenfalls das formularabhängige, verschlüsselte Speichern von Zugangsdaten. Doch wehe, diese Daten, von denen kaum ein User weiß, wo der Browser sie speichert, gehen versehentlich verloren, oder eine Website ändert ihren Domainnamen oder Feldnamen ihrer Login-Formulare — schon ist der Zugang verschlossen. Und auch diese Lösung ist rechnerabhängig.
Die wenigen Glücklichen, die über ein fotografisches Gedächtnis verfügen und all ihre Zugangsdaten jederzeit direkt aus dem Kopf abrufen können, lassen wir mal außen vor. Für alle anderen könnte sich eine weitere Möglichkeit durchsetzen. Diese ist zunächst etwas komplizierter und noch nicht so bekannt, dafür aber zeitgemäß, denn sie arbeitet internet-serverseitig. Zusammengefasst werden die dazu existierenden Ansätze unter dem Begriff Single Sign-On.
Allerdings wird die Bezeichnung „Single Sign-On“ häufig nicht so universell verwendet, wie sie gemeint sein könnte, sondern nur innerhalb eines mehr oder weniger geschlossenen Verbundsystems. So bietet etwa Google ein Single Sign-On für Google Mail, Google Groups, Google Docs, Google Reader und andere Services an. Österreichischen Schülern ist womöglich das Single Sign-On von SbX bekannt, über das der Zugriff auf diverse geschützte Inhalte von Schulbuchverlagen möglich ist. In der universellen Bedeutung ist mit „Single Sign-On“ jedoch nichts Geringeres gemeint als ein Zugang für völlig verschiedene Webangebote, die rein gar nichts voneinander wissen müssen. Das einzige, was sie gemeinsam haben müssen, ist, dass sie die gleiche Single-Sign-On-Schnittstelle unterstützten.
Es gibt verschiedene Lösungsansätze dafür. Die vielleicht bekannteste ist OpenID, das speziell in Europa stark promoted wird. Eine vergleichbare Lösung ist Shibboleth, das für das etwas aus dem Gerede gekommene Internet 2 (jaja, die 2er-Version gabs schon lange vor „Web 2.0“) entwickelt wurde. Dementsprechend ist Shibboleth eher im Bereich von Bildungseinrichtungen verbreitet. Wie auch der zum Thema lesenswerte Blog-Beitrag Sieben Argumente für und gegen OpenID betont, scheint sich die Lösung von OpenID derzeit am ehesten durchzusetzen.
OpenID und vergleichbare Lösungen setzen auf einen sogenannten Identitätsprovider. Bei OpenID wird dieser als OpenID-Provider bezeichnet. Benutzer „hinterlegen“ beim Identitätsprovider ihre echte Identität. Zu den hinterlegten Daten gehört auch eine persönliche URL-Adresse. Ist ein Benutzer bei seinem Identitätsprovider eingeloggt, genügt zum Login bei einer anderen Website, die OpenID unterstützt, die Angabe der persönlichen URL-Adresse. Die Authentifizierung wird dann durch eine Hintergrundkommunikation zwischen der Website, an der sich der Anwender gerade anmelden will, und seinem Identitätsprovider geregelt.
Völlig ausgereift scheint der Ansatz noch nicht zu sein, und von Webanwendungen verlangt er natürlich, dass deren Authentifizierungs-Prozess die OpenID-Schnittstelle unterstützt. Für gängige Webanwendungs-Programmiersprachen gibt es bereits OpenID-Code-Bibliotheken.
Wer des Englischen mächtig ist, findet im OpenID Screencast von Simon Willison eine anschauliche Einführung in Wort und Bild. Danke für diesen Tipp an Tim Tepasse, der im eingangs erwähnten SELFHTML Forums-Thread ebenfalls zu OpenID Stellung genommen hat.